In multi-tenant database systems, customer organizations (also referred to as “tenants”) may share database resources in one logical database. The databases themselves are typically shared, and each tenant is typically associated with an organization identifier (org ID) column or field that may be used to identify rows or records belonging to each tenant. Each tenant may provide their own custom data, which may include defining custom objects and custom fields, as well as designating one or more custom fields to act as custom index fields. The owner/operator of a multi-tenant database system may provide software development platforms (SDPs), integrated development environments (IDEs), software development kits (SDKs), etc. to allow tenants to designate the custom fields and otherwise configure their tenant space within the multi-tenant database system. The owner/operator of a multi-tenant database system may also provide a pre-built and customizable query application for use by agents of the tenants so that these agents can access and/or edit data in the tenant's tenant space. In these cases, the owner/operator of a multi-tenant database system may provide SDPs, IDEs, SDKs, and/or application programming interfaces (APIs) to allow the tenants to customize the query applications. However, organizing and/or controlling revisions to the tenant space configurations and/or revisions to the query applications can be difficult, especially when a tenant uses a relatively large team of developers/administrators to customize the tenant space and/or query applications.
Typical source code management solutions may allow teams of developers to share a central repository of code and declarative structures expressed in source files. These management solutions also allow developers to make changes to source files, merge files containing these structures made by other developers together, and serve the needs of systems for building and releasing software products. In many cases, these management solutions may be SDPs that other third party developers, who do not have access to the source repository, need to use to create their own products. However, typical source code management solutions do not contain mechanisms to ensure that rules, which ensure the structural compatibility of changes/revisions from one release to the next, are respected. The failure to adhere to such rules may be referred to as a “schema evolution” problem. Some solutions to schema evolution problems include publishing development rules so that developers may develop code that complies with the development rules. However, eternalizing the schema evolution rules means that they can themselves be modified as source by developers, providing no guarantee of compatibility. Conversely, while a source code management platform can make use of a centralized online service to ingest various versions of source files to validate them against tables of development rules, such solutions may force all development online, and therefore, may preclude disconnected development. This may burden the rules tables to model the external branching structure of the source code system to ensure that the correct manifest of source files is referenced.